1. Field of the Invention
The present invention relates to communication networks and, more particularly, to a method and apparatus for implementing hub-and-spoke topology virtual private networks.
2. Description of the Related Art
Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
A Virtual Private Network (VPN) may be formed by securing communications between two or more networks or network elements to form a VPN tunnel, such as by encrypting or encapsulating transmissions between the networks or network elements. Using VPN tunnels enables information to be exchanged securely between geographically dispersed sites without obtaining dedicated resources through the network.
To enable devices on one VPN site to communicate with devices on another VPN site via the VPN tunnel, it is necessary to exchange routing information between the two VPN sites. Likewise, as network elements are added and removed from the networks, or as problems are encountered and fixed in the networks, the routing tables need to be updated and advertised to the other participating sites in the VPN.
There are several commonly utilized methods of establishing VPN tunnels on a network. For example, VPNs may be established by customers through the deployment of network elements configured with VPN software. These VPNs will be referred to herein as Customer Premise Equipment-based (CPE-based) VPNs. Another way of establishing VPNs is to configure the VPN at the Provider Edge (PE) network elements to allow the service provider to provision VPN services on behalf of the customer. One common way to do this is described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2547, the content of which is hereby incorporated herein by reference. RFC 2547 describes a VPN architecture in which MultiProtocol Label Switching (MPLS)-based tunnels are used to forward packets over the network backbone. A protocol referred to as Border Gateway Protocol (BGP) is used to distribute routes over the backbone for VPNs provisioned through a particular PE network element. Routing information for these Provider-Provisioned VPNS is stored in a VPN routing and forwarding table (VRF) or a distinguishable area of the PE's common VRF. VPNs established utilizing the 2547 VPN model will be referred to herein as “VRF-based VPNs.”
VRF-based VPNs may be designed to have having many different access topologies. One popular topology is commonly referred to as a “Hub and Spoke” topology. In a hub and spoke topology, the hub controls communications on the VPN such that all spokes can talk to the hub. In a “strict” hub and spoke topology, the spokes are only allowed to talk to the hub. In a “loose” hub and spoke topology, spokes are allowed to talk to each other as well, but may only do so through the hub. This allows the hub to control communication between the spokes.
FIG. 1 illustrates a conventional Hub-and-Spoke (HaSP) VPN topology formed using VRF-based VPNs. As shown in FIG. 1, the VPN service provider provides interconnectivity amongst Customer Edge (CE) network elements 10. A CE device 10 is a device which resides in a VPN site 12 and connects to a Provider Edge node 14. Essentially, a CE device allows the VPN site access to one or more remote VPN sites which belong to the same VPN. A Provider Edge (PE) node is a router which attaches to one or more CE devices and peers using Interior BGP (IBGP) with at least one other PE node. The PE node allows remote access to other VPNs which are locally supported by this PE. When handling Internet Protocol (IP) traffic, a PE node acts as a Label Edge Router which terminates Label Switched Path (LSP) tunnels used to forward traffic to other PE nodes. PE nodes may be directly connected to other PE nodes, or may be connected through other network elements such as backbone routers 16. Backbone routers are commonly designated in the industry by the letter P. The provider “P” router is a backbone router which provides interior gateway protocol connectivity between PE nodes. P routers are generally not connected to CE devices and thus have no need for knowledge of VPN routing information. It may be possible for a given router to act as a PE node for some VPNs and as a P router for other VPNs. The following description will focus on how PE nodes behave and assume an appropriate infrastructure for interconnecting the PE nodes. Also, the behavior of the PE nodes will be described in connection with their participation in a VPN network context. The PE nodes may perform other functions on the network as well, even though that other functionality has not been described herein.
In the VPN network of FIG. 1, a VPN customer has two or more sites that need to be interconnected. In some cases the VPN customers own and manage the CE routers. In other cases, the CE routers are owned and managed by the service provider. The invention discussed below is agnostic as to who actually owns the various components of the network, i.e. one or more network providers and customers may own the CE, PE, and P network elements without affecting the aspects of the invention discussed herein.
As mentioned above, in a Hub-and-Spoke (HaSP) topology, a spoke is defined as a site that must direct traffic to a hub site to communicate with another particular spoke such that no direct inter-spoke traffic is allowed. A HaSP topology may, however, be a sub-part of a larger VPN network topology, and the spokes optionally may be allowed to talk to other portions of the VPN topology directly. Thus, a spoke may be allowed to communicate with other VPN sites not part of the HaSP topology.
Within the HaSP portion of the VPN network, the hub is allowed to receive and send traffic to the spokes of a given VPN. Inter-spoke traffic, however, must goes through a hub to be validated prior to being sent to the target spoke. For example, in the HaSP topology illustrated in FIG. 1, traffic from site 2 to site 3 would follow the path: CE2→PE2→PE1→CE1(hub) →PE1→PE3→CE3. The CE1 or a device behind it is assumed to validate the source and destination site communication privileges using a Network Address Translation (NAT) service, a Fire Wall, an Authentication, Authorization, and Accounting (AAA) service and/or another service.
In HaSP topologies, service providers conventionally create a minimum of two sub-connections between the hub CE and the PE. In FIG. 1, these two connections are designated as connection A and connection B. One of the connections (A) is configured to carry traffic from the source spoke sites toward the hub CE and the other connection (B) is configured to carry traffic from the hub CE toward the destination spoke sites. Each interface on the router associated with these connections (e.g. the interface to link A and the interface to link B) has its own VRF forwarding table. The reason behind this is that a packet destined for CE3 must be treated differently by the PE1 network element depending on where the packet originated. Specifically, if the packet originated at CE2 or another spoke, the packet must be sent to CE1(hub) to be evaluated. If the packet originated at CE1(hub), however, the PE needs to send it to the CE3 network element. The destination address (DA) of each packet, however, is the same in both instances, i.e., the packet is addressed to the DA of CE3. To enable the PE network element to provide differential service to packets having identical DAs based on source of origin, two separate VRFs have conventionally been used—one to handle traffic that is received from the spokes and one for traffic that is received from the hub.
FIG. 2 illustrates a conventional manner of distributing routes in a conventional Hub-and-Spoke (HaSP) network topology. As shown in FIG. 2, when a route R2 is learned by VRF2 on PE2, that route will be distributed throughout the MultiProtocol Label Switching (MPLS) or other domain using Border Gateway Protocol (BGP) in a standard fashion. Although an example using MPLS and BGP will be used to illustrate embodiments of the invention, the invention is not limited to an MPLS/BGP example. Specifically, the route R2 will be exported to PE1 as per VRF2's export policy. In a standard implementation, VRF2 will have an export policy configured to export routes with route targets set to “spoke” and an import policy configured to import routes with route targets set to “hub.” This will be noted herein as Export RT:spoke and Import RT:hub. These policy rules cause the spoke PEs to import routes with route targets set to hub, but not to import routes having one of the spokes as a route target. This prevents spokes from communicating directly with each other and allows the hub to control communication between the spokes.
The learned route, R2, will be distributed throughout the BGP domain and will, thus, be distributed to PE1. The PE1 has two VRFs, one for each link A, B. The inbound VRF, that is configured to handle traffic originating on the spokes and destined for the CE1hub, is set to Import RT:spoke and Export RT:none. This enables the VRFhub-1 to import routes from the spokes but prevents that VRF from exporting those routes to the spokes. The routes, in this case the new route R2, are redistributed to the CE1hub as per VRFhub-1's import policy and other routing policies related to routing between CE1hub and VRFhub-1.
CE1hub is charged with allowing or disallowing relationships. For various reasons, the CE1hub may wish to restrict the ability of the spokes to communicate with each other over particular routes. For example, one of the spokes may relate to a corporation's customer or supplier, and another of the spokes may relate to a branch office. The corporation may not wish the customer/supplier to have access to all of the traffic flowing between the corporation and the branch office. Accordingly, the hub may wish to restrict distribution of routes learned by a spoke to one or more other spokes.
If route R2 is to be distributed to one or more spokes, the VRFhub-2 learns R2 as a local route from CE1hub. VRFhub-2 has an import policy set to import RT:none to prevent it from importing routes advertised on the IP VPN. The import policy is configured, however, to accept routes sent to it from the CE1hub. The export policy for VRFhub2 is configured to export routes provided to it by the hub. In this case, VRFhub2 has a policy Export RT:hub. If approved, R2 is thus exported on the IP VPN with its route designator, also known as the IP-next hop,=hub2, and its route target=hub.
PE devices configured with an import policy Import RT:hub will import the route. PE3, thus, learns route R2 but associates the route target on R2 with the hub and the route designator on route R2 with VRF hub 2. PE2 originated the route R2, so it will already have route R2 in its VRF and will ignore the protocol message containing the route R2 to prevent the formation of a routing loop. The BGP next-hop attribute will be set by the PE and P routers to establish a LSP for the route R2.
Subsequently, if the CE3 has traffic to be sent to the network element associated with R2, it will send the traffic to its connected PE, in this example PE3. PE3 will then obtain the next hop information for the route R2 from VRF3, which will be used to forward the packets toward the PE1 hub. The packets will be sent to the CE1hub for inspection and, if approved, will be passed down the other spoke toward CE2.
Unfortunately, this implementation of a HaSP VPN network topology thus requires the PE hub network elements to create and maintain two VRF forwarding tables—one for each interface that is used to connect to the CE1hub. This increases the cost of providing VPN service for the service provider. Additionally, the customer must purchase connectivity on two separate links, each of which will typically require a service level agreement (SLA). Since most SLAs specify bandwidth in both directions, using one link to transport packets from the PE to the hub and another to transport packets from the hub to the PE results in a waste of network resources. This situation is exacerbated where the connection between the CE-hub and PE network is a multihoming connection, in which redundancy is provided either through the use of multiple CE hubs, multiple PE nodes, multiple links connecting the hubs to the PE nodes, multiple protocol connections, or combinations of these redundancy components.